Medical images (e.g., Magnetic Resonance Imaging (MRI) image) are large. A comparably very small amount of metadata often describes a medical image. The metadata may include, for example an image name, a date acquired, a patient name, a patient identifier, an image size, a billing code, and so on. Once recorded, medical images tend to change relatively infrequently, if at all, as compared to the metadata describing these images. However, changes to metadata may typically have lead to duplication of related medical images, yielding tremendous wastage of computing resources. Similar issues apply to other types of multimedia content (e.g., movies, slide shows).
Conventionally, media databases have managed collections of multimedia content and metadata columns by separating the two items. For example, some medical imaging manufacturers follow the DICOM (Digital Imaging and Communication in Medicine) standard (available at [http://medical.nema.org/dicom/2007/]) for versioning support. This standard requires storing separate copies of the edited medical images. The metadata may typically have been stored in a media content table while the actual image data may have been stored externally in external file storage. Pointers in a media content table may have provided indirect access to the externally stored image files. Conventionally, it has been possible to query the metadata columns in the media content table to acquire pointers to actual files stored in external file storage. Unfortunately, this configuration has had issues with synchronization between metadata and image data, transaction control, security, auditing, backup processing, restoration processing, replication, high availability, versioning, and so on. These issues may have arisen because it is relatively inexpensive (e.g., in time, in resources, in computational complexity) to change a relational database column but relatively expensive to propagate a change to external file storage. Thus, it may have been easy to change metadata but difficult to propagate the change to an image stored in external file storage. Separating the metadata from the image data negatively impacts the features (e.g., versioning) provided by storing things in databases.
To understand an issue with the separated architecture, consider a media query directed at media stored in an external file storage. The media query may be processed by a middle tier that performs query mapping so that a query can be made against metadata stored in a media content table. The metadata acquired in response to this first action can then be used to make a query against an external file where the media data is stored. An assembly process may then be required in the middle tier to associate the initially retrieved metadata with the ultimately retrieved media data. Recall that metadata can easily get out of synchronization with media data, which may yield a complicated, resource-intensive, and not provably correct assembly process for example, when the ordering of DICOM attributes do not follow the DICOM standard (e.g., ascending). These issues may arise in the separated architecture since metadata may be stored as traditional relational database columns with a single version and no update history. In some examples, a single flag may be maintained to indicate whether a metadata modification occurred. When this flag indicates that a metadata change occurred, an entire media (or its header) may be reassembled.
Multimedia content is becoming ubiquitous. Database management systems are now used to store this type of digital media. Some conventional systems process multimedia content by encoding it as a binary stream and then persistently storing the binary stream in a binary large object (BLOB). Some conventional systems may facilitate editing metadata associated with multimedia content. These conventional systems may persistently store and manage the metadata separately from the multimedia content. While the metadata may be retrieved for purposes including querying, auditing, assembling a version, and so on, these conventional systems have drawbacks due to the separate storage. For example, conventional systems are typically inefficient with respect to versioning associated with the metadata edits, if they provide any versioning at all. For example, one conventional system may store the multimedia content as a BLOB and may separately store metadata about the BLOB. However, when changes are made to the metadata, the conventional system may replicate the entire object, including the multimedia content and the metadata attributes, even though only the metadata attributes were changed. Thus, conventional multimedia storage systems may save multiple copies of the same complete multimedia content, which can lead to significant wastage of storage. Additionally, changes to metadata may not be directly independently accessible. For example, accessing the changes to metadata may require accessing an entire BLOB and/or multiple versions of a BLOB.